A certificate authority (CA) issues certificates to subjects, which may be humans or entities such as server computers. A certificate issued to a subject certifies that the subject has some attributes, allowing the subject to prove that it/she/he has such attributes to a third-party, hereinafter referred to as a verifier, that may have no prior relationship with the subject but trusts the CA. A traditional certificate, such as an X.509 certificate described in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 5280 available at https://www.ietf.org/rfc/rfc5280.txt, comprises a public key, attributes, metadata including data items such as a validity period, a serial number, etc., and a signature by the CA. The public key is associated with a private key owned by the subject, the public and private keys forming a key pair pertaining to a public key cryptosystem. The signature binds the public key to the attributes, allowing the subject to demonstrate to the verifier that it/she/he has the attributes by proving possession of the private key.
Before relying on the certificate the verifier must validate it, which requires verifying that it was issued by the CA and has not been revoked. But the validation methods made available by a traditional CA have drawbacks.
Traditionally, a CA revokes a certificate by including its serial number in a certificate revocation list (CRL) signed by the CA, or by configuring an Online Certification Status Protocol (OCSP) server to respond that the certificate has been revoked when queried, or both. Using a CRL has the drawback that it requires the verifier to periodically obtain CRL updates, which is onerous. Relying on a OCSP server prevents the verifier from validating the certificate when the OCSP server is offline, and adds network latency to the presentation of the certificate. The latency impact can be mitigated by a technique known in the art as OCSP stapling when the subject of the certificate is a busy web server, but not when the subject is a human user operating a web browser.
Traditionally, the verifier relies on the signature included in the certificate by the CA to verify that the certificate was issued by the CA. But the presence of the signature in the certificate substantially increases the size of the certificate, which further adds latency when the certificate is presented by the subject to the verifier over a network with limited bandwidth.
Therefore there is a need for non-traditional CAs that support better methods of validating certificates.